ATOM Documentation

← Back to App

Security Architecture & Governance

The ATOM Agent OS – SaaS Platform implements a multi-layered **Defense-in-Depth** model to ensure strict tenant isolation, safe autonomous execution, and transparent neural governance.

---

🛡️ The 5 Layers of Tenant Isolation

ATOM SaaS provides physical and logical separation of data at every tier of the execution stack.

1. Database-Level Locking (RLS)

The most critical security layer is PostgreSQL **Row-Level Security (RLS)**. Every table is enabled with a policy that automatically filters all SELECT, UPDATE, and DELETE operations based on the current_tenant_id session variable.

2. Physical Resource Segregation

  • **Storage (S3)**: Files are stored under tenant-specific prefixes: s3://atom-saas/{tenant_id}/.
  • **Memory (Redis)**: All keys are namespaced: tenant:{tenant_id}:{key}.
  • **Vector Search (LanceDB)**: Experience memory is partitioned per tenant to prevent cross-intelligence leakage.

---

🏗️ Autonomous Execution Security

Agents are restricted in their ability to interact with the underlying infrastructure through three primary mechanisms.

1. Terminal Command Whitelisting

All terminal skill executions pass through a **Command Sanitizer**. By default, dangerous commands (e.g., rm, sudo, curl) are blocked.

  • **Tier-Based Access**: Premium tiers (Solo+) gain access to network tools like ssh and rsync.
  • **Modes**: Tenants can switch between Restrictive (Whitelist only) and Permissive (All except Blacklist) modes.
  • Terminal Security Guide →

2. Package Management & Scanning

Before an agent installs a Python dependency for a custom skill:

  • **Whitelist Check**: The package must be approved for the agent's maturity level (STUDENT, INTERN, etc.).
  • **Vulnerability Scan**: Every package is scanned with pip-audit via the **PackageScannerService**.
  • **Isolation**: Each skill is executed within its own isolated virtualenv.
  • Package Management Guide →

---

🧠 Neural Governance & Interventions

Security in ATOM is not just about blocking; it's about **Human-in-the-Loop** control.

1. The Maturity Loop

Agents follow a maturity progression path. High-risk actions (e.g., executing shell scripts, managing billing) are restricted to **Supervised** or **Autonomous** agents who have passed a specific readiness score threshold.

2. Administrative Interventions

High-stakes agent actions can trigger an **Intervention Requirement**.

  • **Governance Portal**: Admins review "Blocked Actions" and can manually approve or deny them.
  • **Neural Spend Attribution**: Real-time monitoring of token usage per-tenant and per-agent prevents adversarial "bill-burning."

---

📂 Security Reference Directory

---

**Last Updated**: March 2026

**Security Audit Status**: 212 E2E tests passing with 100% isolation compliance.